The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority. Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs. Learn more.

Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Does anyone know how long it usually takes for us to hear back from Apple regarding a request for Location Push Service Extension entitlement?

Hi, We operate several iOS apps that use APNs through the HTTP/2 provider API. Since around May 12, we have observed a significant drop in APNs HTTP/410 “Unregistered” responses across multiple apps / bundle IDs. There have been no relevant changes on our side around that time. Our APNs integration, request flow, credentials, and push token handling have remained unchanged. What makes this more confusing is that App Store Connect does not show a corresponding drop in app deletion events for the same apps and time period. In other words, the app deletion trend appears stable in App Store Connect, but APNs 410 “Unregistered” responses dropped sharply. We understand that APNs does not guarantee an immediate 410 response after an app uninstall, and that the exact token invalidation timing is not documented. However, the aggregate change in 410 response volume is large enough that it looks like a behavior change. Questions: Has there been any recent APNs behavior change around when device tokens are marked inactive after an app is uninstalled? Were there any APNs-side changes around May 12 that could affect the rate of HTTP/410 “Unregistered” responses? Why might App Store Connect app deletion events remain stable while APNs 410 “Unregistered” responses drop significantly? Is APNs expected to return HTTP/200 for an extended period for tokens that may no longer be active for the topic? Thanks.

Platform and Version Platform: iOS iOS Version: 17.0+ Development Environment: .NET MAUI (C#, .NET 9) Network Layer: HttpClient with HttpClientHandler Description of the Problem We are facing an issue where HttpClientHandler.ServerCertificateCustomValidationCallback is not being invoked when the app is in a terminated (kill) state. In normal app lifecycle states (foreground/background), the callback is triggered as expected and allows us to handle server certificate validation (e.g., for certificate pinning or custom validation logic). However, when the app is in a killed state and is relaunched due to a notification action, the callback does not execute. We would like to understand: Why ServerCertificateCustomValidationCallback is not invoked in this scenario Whether this behavior is expected within iOS networking/runtime constraints Any recommended approach or workaround to ensure certificate validation still occurs when handling notification-triggered flows from a terminated state Steps to Reproduce Ensure the app is force-terminated (kill mode) Configure a push notification with category: "INVITE_CATEGORY" Include custom notification action buttons Tap one of the custom actions This triggers app launch and network call using HttpClient Expected Behavior ServerCertificateCustomValidationCallback should be invoked during the network request initiated after tapping the notification action, allowing custom certificate validation.

We have an app that uses PushKit and CallKit for video calling. These are often emergency calls, so very latency-sensitive. We keep track of when we sent out the APNs request and when the phone started ringing. The p95 latency is about 2 seconds (mean is ~800ms), which feels quite long.. Is this normal? I'd expect <500ms most of the time given that the devices and servers are all within the US. The users typically have a stable internet connection. Our requests look like this: POST https://api.push.apple.com/3/device/<DEVICE_TOKEN> apns-topic: com.vpt.physician.voip apns-push-type: voip apns-priority: 10 apns-expiration: 0 authorization: bearer <APNS_PROVIDER_TOKEN> content-type: application/json {  "aps": {    "content-available": 1  },  "title": "Example Text",  "type": "CallFromTablet",  "timeout_ms": 30000 } If there's any more info I can provide to help troubleshoot this, let me know. Thanks in advance.

Hi, am facing an issue related to voip push notifications getting delivered 1-2 hours after apns-expiration to 0 and apns-priority to 10. I had raised a similar post got a reply that it may be due to network delay. But network delay can cause the delivery of voip push to be delayed only by few seconds or minutes. But in our case voip push is getting delivered hours after the voip call was attempted. Steps to reproduce: Put our voip app in background and lock iPhone. As app is put in background, socket connections gets disconnected from server. Now if a caller makes call to this app, the call should be delivered through voip push. 2) Voip push should ideally be received even if app is in background and iPhone is locked. It is connected to a good wifi network. But it does not receive the voip push. 3) After 1-2 hours user unlocks iPhone and opens voip app. As soon as user opens app, the voip push is received and phone starts ringing.

My auto-renewable subscription products are approved in App Store Connect, but fetchProducts() returns 0 products when testing in Production & Testflight. Debug output shows: "products.size is 0 - no products fetched! Expected 6 products." All my business agreements are active. Has anyone faced this before? What do you recommend? Thank you.

Hello, We are planning to transfer an app to a different Apple Developer account and had several questions regarding APNs continuity and behavior after the transfer. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. I’ve done some due diligence on this topic within the forums and found related guidance here: https://developer.apple.com/forums/thread/744468?answerId=776692022#776692022 My understanding from that thread is that the existing push notification credentials will become invalid after a short delay following the transfer, and that we would need to update our backend to use newly generated credentials from the recipient account. However, since things can evolve over time, I wanted to confirm whether that guidance is still accurate for the following scenarios. For users who already have the app installed and previously opted into push notifications before the transfer: Will existing APNs device tokens remain valid after the app transfer? Will these users continue receiving push notifications without interruption, assuming our provider infrastructure remains unchanged? For users who newly install the app after the transfer: Will we need to migrate to a new APNs authentication key or certificate associated with the recipient Apple Developer account in order to successfully register for and send push notifications to those users? For users who restore or migrate the app to a new device (for example, via iCloud Backup restore or device-to-device transfer): Will push notification registration continue to function normally after the app transfer? Will those app instances need to re-register and obtain new APNs device tokens associated with the recipient account? To support this scenario, would our provider infrastructure need to migrate to and use a new APNs authentication key associated with the recipient account? Any clarification on the expected APNs transition behavior during and after an app transfer would be greatly appreciated. Thank you.

Hello, We are going to transfer our App to another company’s Apple Developer account. We have been using P12 certificates and P8 keys for APNs push service, and we have several inquiries: Will the current P12 push certificates expire instantly after successful App transfer? Is it mandatory to recreate P12 certificates under the new account? Will existing P8 keys be disabled immediately after the ownership transfer? Do we need to generate new P8 keys under the new account? Without releasing new App builds and updating push credentials after the transfer, can existing end users still receive normal push notifications? Thanks a lot for your assistance, waiting for your reply.

Hello, I have a question regarding push services after app transfer completion and hope you can clarify it for me: If the original team does not actively disable existing APNs and JWT connections as well as push services, will the old P12 certificates and P8 keys remain valid for a short while so users can still receive push notifications? If yes, the new company only needs to finish certificate updates shortly after receiving the transfer success notice. How many hours is this grace period normally? Whether the original team shuts down APNs and JWT services or not, will the old P12 certificates and P8 keys become invalid right away, leaving users unable to receive pushes until the new company updates the relevant credentials? Thanks for your support and looking forward to your reply.

Hi, We're implementing a DDM-capable MDM server. A DEP-enrolled, supervised iPad (iOS 26.4.2) successfully completes manifest synchronization but never proceeds to fetch the individual declaration bodies. Looking for guidance on what we might be missing. Observed flow (from our server logs): We enqueue a DeclarativeManagement MDM command and APNs-wake the device. The command body is: RequestTypeDeclarativeManagement (no Data field) Device acknowledges the command on the Connect endpoint (Status=Acknowledged). Device calls CheckIn with: MessageType = DeclarativeManagement Endpoint = tokens We respond 200 with: { "SyncTokens": { "DeclarationsToken": "", "Timestamp": "2026-05-19T..." } } Device calls CheckIn with: MessageType = DeclarativeManagement Endpoint = declaration-items We respond 200 with: { "Declarations": { "Activations": [{"Identifier":"...","ServerToken":"v1-..."}], "Configurations": [{"Identifier":"...","ServerToken":"v1-..."}], "Assets": [], "Management": [] }, "DeclarationsToken": "" } ---- Nothing further. ---- No request for Endpoint = declaration/activation/ No request for Endpoint = declaration/configuration/ No status report on Endpoint = status The MDM channel is healthy. The same device responds normally to non-DDM commands (DeviceInformation, etc.) immediately before and after this flow. Questions: Is an empty "Management" array acceptable in the declaration-items response, or is at least one declaration (e.g. com.apple.management. organization-info) required before the device will proceed to fetch declaration bodies? The DeclarationsToken returned in step 3 (tokens) and step 4 (declaration-items) are byte-identical. Is that correct, or should they differ in some way? Are there any additional preconditions for the device to begin fetching declaration bodies after receiving the manifest -- e.g. a specific Activation->Configuration linkage we might be missing? Is there a server-side log signal Apple can suggest we look for, or a way to see why the device decided not to fetch? Activation payload sample we publish: { "Type": "com.apple.activation.simple", "Identifier": "...", "ServerToken": "v1-...", "Payload": { "StandardConfigurations": ["<configuration-identifier-from-step-4>"] } } Configuration payload sample we publish: { "Type": "com.apple.configuration.softwareupdate.settings", "Identifier": "...", "ServerToken": "v1-...", "Payload": { ... softwareupdate settings ... } } Any pointers appreciated. Happy to share full server-side logs / payloads if useful. Thanks.

I'm seeing a timestamp display issue on Apple Watch Notification Center, and I'd like to confirm whether this is a known watchOS behavior or whether there's a setup mistake on our side. Symptom The same APNs notification displays the correct time on iPhone Notification Center and on the initial Apple Watch banner. After the Watch screen turns off and the user later opens Notification Center on Apple Watch, the same notification may show an incorrect relative timestamp such as "3 hours ago" or even "yesterday". The drift is per-notification and persists for that notification until it's dismissed. iPhone NC always shows the correct time. WhatsApp tested side-by-side on the same iPhone/Watch pair does not show this drift. Setup iOS 26.4.2 on iPhone 16 Pro watchOS 26.4 on Apple Watch Series 10 App with paired Apple Watch A UNNotificationServiceExtension that decrypts E2EE message previews and applies Communication Notification enrichment via INSendMessageIntent and content.updating(from:) Production APNs environment, TestFlight builds No beta software Isolation tests already performed Test mutable-content NSE invoked Drift on Watch NC Minimal APNs (alert + sound only) no no no drift NSE skips content.updating(from:), INInteraction.donate/delete (still calls them as no-op via diagnostic build) yes yes — modifies content drift NSE bypasses ALL Intents/Communication Notification APIs (no INPerson, no INSendMessageIntent, no avatar, no updating(from:)); just modifies title/body/sound/category and returns the mutable copy yes yes — modifies content drift Production-like APNs payload (thread-id, target-content-id, category, sound, badge, custom userInfo) but WITHOUT mutable-content no no no drift Eliminated as causes: content.updating(from:), INSendMessageIntent, INInteraction.donate, INInteraction.delete(with:), INPerson/INPersonHandle (not even constructed in test 3), avatar fetching, thread-id, target-content-id, category, sound, badge, custom userInfo, custom createdAt timestamp, stale Siri/Apple Intelligence history (cleared manually on iPhone and Watch). The pattern The only consistent variable distinguishing the no-drift cases from the drift cases is whether mutable-content: 1 is set on the APNs payload (i.e. whether the UNNotificationServiceExtension is invoked). Once invoked, the extension's behavior with respect to Communication Notifications does not seem to affect the outcome — the drift reproduces even when the NSE only modifies title/body/sound and returns. Questions Is there a known watchOS behavior where notifications processed by a UNNotificationServiceExtension use a different timestamp source on Apple Watch Notification Center after the Watch screen has been turned off and reopened, while the initial Watch banner and iPhone Notification Center show the correct delivery time? Are there specific UNMutableNotificationContent properties or APNs payload flags that should be preserved (or avoided) when returning content from an NSE to keep the Watch NC timestamp consistent with the delivery time? For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS? Happy to provide an anonymized snippet of NotificationService.swift and the APNs payload format if useful. Thanks.

Hi, I have a question regarding the relationship between the Apple Developer Enterprise Program membership and an existing APNs certificate used for MDM. Current Situation We are operating an MDM server. We have already obtained a valid APNs certificate via the Apple Push Certificates Portal. Our Apple Developer Enterprise Program membership is about to expire. The only asset we have in the Enterprise account is the MDM CSR used during the APNs certificate issuance process. Question If the Apple Developer Enterprise Program Membership expires: Will the existing APNs certificate remain valid until its expiration date? Or will it become invalid immediately due to the account expiration? Thank you.

I have a live activity and even after a couple of times that it has shown on my lock screen it keeps prompting the user to tap on Don't Allow or Allow. Can someone help me understand why this is happening? I would like my users to only hit Allow once and not be prompted again, otherwise they would not be registered for updates, since update token only generates after selecting Allow.

We have a VPN app that uses NEPacketTunnelProvider with includeAllNetworks = true. We've encountered an issue where push notifications are not delivered over Wi-Fi while the tunnel is active in a pre-MFA quarantine state (tunnel is up but traffic is blocked on server side), regardless of whether excludeAPNS is set to true or false. Observed behavior Wi-Fi excludeAPNS = true - Notifications not delivered Wi-Fi excludeAPNS = false - Notifications not delivered Cellular excludeAPNS = true - Notifications delivered Cellular excludeAPNS = false - Notifications not delivered On cellular, the behavior matches our expectations: setting excludeAPNS = true allows APNS traffic to bypass the tunnel and notifications arrive; setting it to false routes APNS through the tunnel and notifications are blocked (as expected for a non-forwarding tunnel). On Wi-Fi, notifications fail to deliver in both cases. Our question Is this expected behavior when includeAllNetworks is enabled on Wi-Fi, or is this a known issue / bug with APNS delivery? Is there something else in the Wi-Fi networking path that includeAllNetworks affects beyond routing, which could prevent APNS from functioning even when the traffic is excluded from the tunnel? Sample Project Below is the minimal code that reproduces this issue. The project has two targets: a main app and a Network Extension. The tunnel provider captures all IPv4 and IPv6 traffic via default routes but does not forward packets — simulating a pre-MFA quarantine state. The main app configures the tunnel with includeAllNetworks = true and provides a UI toggle for excludeAPNS. PacketTunnelProvider.swift (Network Extension target): import NetworkExtension class PacketTunnelProvider: NEPacketTunnelProvider { override func startTunnel(options: [String : NSObject]?, completionHandler: @escaping (Error?) -> Void) { let settings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "127.0.0.1") let ipv4 = NEIPv4Settings(addresses: ["198.51.100.1"], subnetMasks: ["255.255.255.0"]) ipv4.includedRoutes = [NEIPv4Route.default()] settings.ipv4Settings = ipv4 let ipv6 = NEIPv6Settings(addresses: ["fd00::1"], networkPrefixLengths: [64]) ipv6.includedRoutes = [NEIPv6Route.default()] settings.ipv6Settings = ipv6 let dns = NEDNSSettings(servers: ["198.51.100.1"]) settings.dnsSettings = dns settings.mtu = 1400 setTunnelNetworkSettings(settings) { error in if let error = error { completionHandler(error) return } self.readPackets() completionHandler(nil) } } private func readPackets() { packetFlow.readPackets { [weak self] packets, protocols in self?.readPackets() } } override func stopTunnel(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) { completionHandler() } override func handleAppMessage(_ messageData: Data, completionHandler: ((Data?) -> Void)?) { if let handler = completionHandler { handler(messageData) } } override func sleep(completionHandler: @escaping () -> Void) { completionHandler() } override func wake() { } } ContentView.swift (Main app target) — trimmed to essentials: import SwiftUI import NetworkExtension struct ContentView: View { @State private var excludeAPNs = false @State private var manager: NETunnelProviderManager? var body: some View { VStack { Toggle("Exclude APNs", isOn: $excludeAPNs) .onChange(of: excludeAPNs) { Task { await saveAndReload() } } Button("Connect") { Task { await toggleVPN() } } } .padding() .task { await loadManager() } } private func loadManager() async { let managers = try? await NETunnelProviderManager.loadAllFromPreferences() if let existing = managers?.first { manager = existing } else { let m = NETunnelProviderManager() let proto = NETunnelProviderProtocol() proto.providerBundleIdentifier = "<your-extension-bundle-id>" proto.serverAddress = "127.0.0.1" proto.includeAllNetworks = true proto.excludeAPNs = excludeAPNs m.protocolConfiguration = proto m.localizedDescription = "TestVPN" m.isEnabled = true try? await m.saveToPreferences() try? await m.loadFromPreferences() manager = m } if let proto = manager?.protocolConfiguration as? NETunnelProviderProtocol { excludeAPNs = proto.excludeAPNs } } private func saveAndReload() async { guard let manager else { return } if let proto = manager.protocolConfiguration as? NETunnelProviderProtocol { proto.includeAllNetworks = true proto.excludeAPNs = excludeAPNs } manager.isEnabled = true try? await manager.saveToPreferences() try? await manager.loadFromPreferences() } private func toggleVPN() async { guard let manager else { return } if manager.connection.status == .connected { manager.connection.stopVPNTunnel() } else { await saveAndReload() try? manager.connection.startVPNTunnel() } } } Steps to reproduce Build and run the sample project with above code on a physical iOS device. Connect to a Wi-Fi network. Set excludeAPNS = true using the toggle and tap Connect. Send a push notification to the device to a test app with remote notification capability (e.g., via a test push service or the push notification console). Observe that the notification is not delivered. Disconnect. Switch to cellular. Reconnect with the same settings. Send the same push notification — observe that it is delivered. Environment iOS 26.2 Xcode 26.2 Physical device (iPhone 15 Pro)

I'm adding live activities to my app and I'm trying to use push notifications to fully remotely start them and end them. The pushToStartTokenUpdates sequence gives start tokens exactly as expected, and triggers even when the app is fully terminated when a new live activity starts. However, the pushTokenUpdates sequence is far less predictable and seems to never trigger when the app is fully terminated. Even when the app is just backgrounded, it's still finicky. I send the "input-push-token": 1 as part of the aps payload too to begin the live activity, but that seems to have little to no effect. Is there any way to ensure that we can receive a push token specifically to update the live activity after it starts? It seems to me that if a live activity can be started via push even when the app is fully terminated, and live activities are meant to reflect active information, then the mechanism to update it via a new token should also be able to work when the app is terminated. Both sequences are subscribed to within the AppDelegate upon initial app launch. This is what my code looks like at the moment: func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { Task { for await newToken in Activity<WidgetAttributes>.pushToStartTokenUpdates { let tokenString = newToken.map{ String(format: "%02x", $0) }.joined() // send to server } } Task { for await activity in Activity<WidgetAttributes>.activityUpdates { Task { for await token in activity.pushTokenUpdates { let tokenString = token.map { String(format: "%02x", $0) }.joined() // send to server } } } } } } Thanks in advance for any insights!

Hi everyone, I have a question about Live Activity start tokens and update tokens. After reading the documentation, it is still not very clear to me how often these tokens are invalidated, and whether their expiration is time-based or event-based. My current understanding is that the update token is generated when the Live Activity starts, and that it becomes invalid when the activity ends or is dismissed by the user. What I am not clear on is whether the update token can also become invalid at any point while the Live Activity is still active. I have a similar question about the start token. I have noticed that it is generated on the initial app launch, but I have also seen it get regenerated at what seems like random times. I would like to better understand what events or conditions cause a new start token to be issued. Is there any official guidance on the lifecycle of these tokens, specifically: whether they expire based on time, whether they are only invalidated by specific events, and what conditions trigger regeneration of the start token or update token? Any clarification would be appreciated. Thanks.

Hi everyone, I have two questions about Live Activity push notifications that we send from our backend server to iPhones. First, I would like to understand the expected behavior when lowering the APNs priority of a Live Activity update from 10 to 6. How does this affect delivery timing, reliability, or system handling of the notification? Second, my team has been seeing significant delays with some messages sent to the device. In some cases, notifications take anywhere from 1 to 3 hours to arrive on the phone. We are trying to understand what might cause this kind of delay. Is this expected under certain conditions, such as device state, system throttling, network conditions, or APNs behavior? Also, is there any way to inspect logs or delivery details for messages sent to the app so we can better diagnose where the delay is happening? Any guidance would be appreciated. Thanks.

In my VoIP app, we use StartRing and StopRing via VoIP push to my app. But recently, I found some disordered VoIP notifications, my VoIP app received the StopRing push before the StartRing push. Examples: Server log: // send StartRing startring: - Apr 9, 2026 @ 14:54:43.255 .."pushType":"voip","priority":10, ... // send StopRing stop-ring Apr 9, 2026 @ 14:54:47.645 ..."pushType":"background","priority":5,"... VoIP app log: // receive StopRing 2026-04-0909:54:48.858 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StopRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 // receive StartRing 2026-04-0909:54:49.524 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StartRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 Then we can see the StartRing send first, but received in the app after the StopRing. The StartRing took abunt 6s to send and the StopRing took about 1s. So I guess there is an issue in the APNs part on iOS26.4. We saw there is a peak after iOS26.4 and iOS 26.4.1 than old iOS versions. Thanks.

Hey guys, I made a app that features push notificaions, and I keep having problems setting them up. It asks permissions, and then it says that it cannot get the APN token after 10 seconds, and I am positive that I have enabled Push Notificaions in the provisioning profile in Xcode. Can anyone help me fix this issue?

Hello, We are experiencing an issue related to push notifications after updating devices to iOS 26.4 Beta. Our system stores push notification tokens on the server by associating the device token with the device’s IDFV in the app. After updating a device to iOS 26.4 Beta, we observed that the device token from a previously uninstalled version of the app remains valid for more than a week. As a result, two push notifications are delivered to the same device. The situation is as follows: The user installs the app and a device token is generated. The user uninstalls the app. Later, the user installs the app again and a new device token is generated. However, the previous device token does not become invalid, even after more than a week. Because IDFV changes when the app is reinstalled, our server cannot determine that the device belongs to the same user. Therefore, we cannot overwrite the old token with the new one on the server side. Could you please advise: Is this behavior expected in iOS 26.4 Beta? How long does it normally take for a device token to become invalid after an app is uninstalled? What is the recommended approach to prevent duplicate push notifications in this situation? Any guidance would be greatly appreciated. Best regards